您可以使用宽松模式的流量泳道实现应用版本隔离,基于链路透传请求头和引流请求头,将流量路由到不同泳道。泳道中服务相互调用时,若目标服务不存在当前泳道则转发至基线泳道,保障链路完整性,简化流量管理。
前提条件
已添加集群到ASM实例。具体操作,请参见添加集群到ASM实例。
已创建名称为ingressgateway的ASM网关。具体操作,请参见创建入口网关服务。
已创建名称为ingressgateway且命名空间为istio-system的网关规则。具体操作,请参见管理网关规则。
功能介绍
服务网格ASM支持通过宽松模式的流量泳道将应用的相关版本(或其他特征)隔离成不同的运行环境。在宽松模式下,您只需要确保创建一条包含调用链路中所有服务的泳道:基线泳道。其他泳道可以不包含调用链路上的全部服务。当一个泳道中的服务进行相互调用时,若目标服务在当前泳道中不存在,则请求将被转发到基线泳道中的相同服务,并在请求目标存在当前泳道中存在时将请求重新转发回当前泳道。使用宽松模式的流量泳道时,您的应用程序必须包含一个能够在整条调用链路中透传的请求头(链路透传请求头),且链路透传请求头的值对于每条请求都各不相同。同时,您需要指定一个引流请求头,ASM网关将会根据引流请求头的内容将流量发往不同的流量泳道。
本示例使用mocka、mockb、mockc三个服务创建代表服务调用链三个版本的三个泳道:s1、s2、s3。其中s1为基线泳道,包含完整的三个服务,s2仅包含mocka和mockc两个服务,s3仅包含mockb一个服务。
对于以上的宽松模式流量泳道使用场景,您的应用程序必须包含一个能够在整条调用链路中透传的请求头(链路透传请求头),且链路透传请求头的值对于每条请求都各不相同。您可以将应用程序接入链路追踪系统,并将链路ID请求头作为链路透传请求头使用(例如x-b3-trace-id)。
如果您的应用程序未接入链路追踪系统,可以参考自动插装,使用OpenTelemetry Operator为应用程序注入自动插装能力来实现对链路ID请求头的透传,而无需修改应用程序代码。要完成自动插装,您需要跟随上述社区文档完成OpenTelemetry Operator的安装、自动插装的配置,以及为应用Pod加入annotation的一系列步骤。OpenTelemetry自动插装支持多种常见的分布式链路上下文透传标准(如W3C TraceContext、W3C Baggage、B3等)。以上述的自动插装社区文档为例,该文档提供了W3C TraceContext和W3C Baggage的透传示例;配置完成后,您可以利用W3C TraceContext的链路透传请求头traceparent来完成本文中泳道的配置,将本文中使用的链路透传请求头my-request-id替换为W3C TraceContext的透传请求头traceparent即可。
步骤一:部署示例服务
为default命名空间启用Sidecar网格代理自动注入。具体操作,请参见启用自动注入。
关于自动注入的更多信息,请参见配置Sidecar注入策略。
在ACK集群中执行以下命令,部署示例服务。
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml
步骤二:创建泳道组和对应泳道
创建泳道组。
登录ASM控制台,在左侧导航栏,选择 。
在网格管理页面,单击目标实例名称,然后在左侧导航栏,选择 。
在流量泳道页面,单击创建泳道组,在创建泳道组面板,配置相关信息,然后单击确定。
配置项
说明
泳道组名称
本示例配置为test。
入口网关
选择ingressgateway。
泳道模式
选择宽松模式。
请求头设定
链路透传请求头:由于示例应用在调用链路中透传了请求头my-request-id,因此本示例配置为my-request-id。
引流请求头:用于网关根据请求头内容向不同泳道引流及泳道上下文保持,可任意指定。本示例配置为x-asm-prefer-tag。
泳道服务
选择目标Kubernetes集群和default命名空间,在下方列表中选中mocka、mockb和mockc服务,单击图标,添加目标服务到已选择区域。
配置完成后,会自动生成对应的流量标签TrafficLabel。您可以在控制台左侧导航栏,单击流量标签进行查看。例如,针对mocka服务会生成如下的TrafficLabel。
创建s1、s2、s3泳道,并分别绑定v1、v2、v3版本。
在流量泳道页面的流量规则定义区域,单击创建泳道。
在创建泳道对话框,配置相关信息,然后单击确定。
配置项
说明
泳道名称
三条泳道分别配置为s1、s2、s3。
配置服务标签
标签名称:选择ASM_TRAFFIC_TAG
标签值:三条泳道分别选择v1、v2、v3。
添加服务
s1泳道:选择mocka(default)、mockb(default)、mockc(default)。
s2泳道:选择mocka(default)、mockc(default)。
s3泳道:选择mockb(default)。
创建s1泳道的示例图如下:
三个泳道创建完成后,示例效果如下:
三个泳道创建完成后,针对泳道组中的每个服务都将生成泳道规则对应的目标规则DestinationRule和虚拟服务VirtualService。您可以在控制台左侧导航栏,选择
或虚拟服务进行查看。例如,针对mocka服务会自动创建如下DestinationRule和VirtualService。
创建三个泳道对应的引流规则。
在流量泳道页面的流量规则定义区域,单击目标泳道右侧操作列下的引流规则。
在添加引流规则对话框,配置相关信息,然后单击确定。
本文以泳道服务对应入口API均为
/mock
为例,为每个泳道配置相同的引流规则。配置项
说明
入口服务
选择mocka.default.svc.cluster.local。
引流规则
配置三个泳道引流规则的名称分别为r1、r2、r3,域名为*。
匹配请求的URI
配置匹配方式为精确,匹配内容为/mock。
为s1泳道添加引流规则的示例图如下:
三个泳道的引流规则创建成功后,示例效果如下:
创建成功后,会自动生成每条泳道的引流规则,即虚拟服务VirtualService。例如,针对泳道s2会生成如下的虚拟服务VirtualService。
步骤三:验证全链路灰度功能是否生效
获取ASM网关的公网IP。具体操作,请参见获取ASM网关地址。
执行以下命令,设置环境变量。
xxx.xxx.xxx.xxx
为上一步获取的IP。export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
验证全链路灰度功能是否生效。
执行以下命令,查看s1泳道的访问效果。
x-asm-prefer-tag
对应的值s1
为步骤二.2创建s1泳道时配置的泳道名称。for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
由预期输出得到,通过设置HTTP标头
x-asm-prefer-tag: s1
声明的流量流向s1泳道下的相关服务,符合预期。执行以下命令,查看s2泳道的访问效果。
x-asm-prefer-tag
对应的值s2
为步骤二.2创建s2泳道时配置的泳道名称。for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v2, ip: 172.17.0.128)
由预期输出得到,通过设置HTTP标头
x-asm-prefer-tag: s2
声明的流量流向s2泳道下的相关服务。当流量发往泳道s2中不存在的服务mockb时,流量通过回退机制发往基线泳道s1中的mockb服务,后续流量发往mockc服务时,目标重新设定为s2泳道中的mockc服务,符合预期。执行以下命令,查看s3泳道的访问效果。
x-asm-prefer-tag
对应的值s3
为步骤二.2创建s3泳道时配置的泳道名称。for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
由预期输出得到,通过设置HTTP标头
x-asm-prefer-tag: s3
声明的流量流向s3泳道下的相关服务。当流量发往泳道s3中不存在的服务mocka、mockc时,流量通过回退机制发往基线泳道s1中的mocka、mockc服务,符合预期。
相关操作
在宽松模式中修改基线泳道
修改基线泳道的前提是已创建宽松模式的泳道组,并在泳道组中创建至少两个泳道。
默认情况下,您在泳道组中创建的第一个泳道将被设定为基线泳道。您可以修改基线泳道,当流量发往其他泳道中不存在的服务时,通过回退机制将请求转发至基线泳道。
登录ASM控制台,在左侧导航栏,选择 。
在网格管理页面,单击目标实例名称,然后在左侧导航栏,选择 。
在流量泳道页面的目标泳道组页签,在流量规则定义区域,单击基线泳道右侧的图标。
选择变更的基线泳道名称,然后单击确定修改。
相关文档
流量泳道分为严格与宽松两种模式。关于两种模式的说明和差异,请参见流量泳道概述。
如果您需要同时将链路透传请求头指定为引流请求头,实现全链路流量管理,请参见场景二:在链路中已透传引流请求头。
您可以基于VirtualService和DestinationRule等流量规则实现流量泳道,同时通过配置流量降级,在某个版本(或者其他特征)的应用不可用时,将流量发往一个指定的降级版本(或其他特征)的应用。具体操作,请参见基于流量规则配置实现流量泳道和流量降级。
- 本页导读 (1)